Skip to content

(WIP) TS: fast forward and propagation policy change#10576

Open
feiyang3cat wants to merge 11 commits into
temporalio:mainfrom
feiyang3cat:ts-fast-forward
Open

(WIP) TS: fast forward and propagation policy change#10576
feiyang3cat wants to merge 11 commits into
temporalio:mainfrom
feiyang3cat:ts-fast-forward

Conversation

@feiyang3cat

@feiyang3cat feiyang3cat commented Jun 6, 2026

Copy link
Copy Markdown
Contributor

What changed and why

  1. make server compatible to breaking api change
    time skipping fast forward api#786

  2. change the propagation policy of time skipping to

  • for the same execution (a chain of runs) all time skipping state and config are shared using StatePropagation
  • for child executions
    virtual time is always propagated to have causal time
    but the fast forward action is never propagated
    configuration propagation is controlled by a separate flag
  1. rename bound to fast-forward

How did you test it?

  • built
  • run locally and tested manually
  • covered by existing tests
  • added new unit test(s)
  • added new functional test(s)

Potential risks

the sequence of this pr

  1. review this pr first 2. merge api 3. update this pr with public api dependency and merge

@feiyang3cat feiyang3cat requested review from a team as code owners June 6, 2026 03:49
@feiyang3cat feiyang3cat force-pushed the ts-fast-forward branch 6 times, most recently from d5aa678 to ad54d2d Compare June 8, 2026 17:23
@feiyang3cat feiyang3cat force-pushed the ts-fast-forward branch 2 times, most recently from 861e03b to b46afaa Compare June 10, 2026 16:34
Comment thread proto/internal/temporal/server/api/persistence/v1/executions.proto Outdated
Comment thread service/history/api/updateworkflowoptions/api.go Outdated
@feiyang3cat feiyang3cat force-pushed the ts-fast-forward branch 3 times, most recently from 9ae6e10 to 5d05103 Compare June 10, 2026 18:19
@feiyang3cat feiyang3cat changed the title Ts: api change to fast forward TS: fast forward and propagation policy change Jun 10, 2026
@feiyang3cat feiyang3cat force-pushed the ts-fast-forward branch 5 times, most recently from 1000c5e to 1753d5b Compare June 10, 2026 21:20
disableChildPropagation := source.GetTimeSkippingInfo().GetConfig().GetDisableChildPropagation()
enabled := source.GetTimeSkippingInfo().GetConfig().GetEnabled()
if !enabled || disableChildPropagation {
return nil, nil

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we do not propagate the virtual time to the child in this case? This contradicts the described behavior in API PR:

// but a parent's fast_forward won't affect its child's execution. A flag is provided to disable propagation of the
// "enabled" flag to child workflows; regardless of that flag, a child workflow inherits the virtual time from the
// parent execution as its start time.```

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a bug

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

func (ms *MutableStateImpl) applyTimeSkippingBound(currentEventID int64) {
// applyFastForward (re)computes the FastForwardInfo using the new TimeSkippingConfig and propagated time-skippingstates.
// This method should be called whenever the TimeSkippingConfig is initialized or updated.
func (ms *MutableStateImpl) applyFastForward(currentEventID int64, propagatedTargetTime *timestamppb.Timestamp) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this get executed even when unrelated field is updated? So say you have a 2h fast-forward set and you are 1 hour into it. If you update some other workflow option, it looks like you would just recalculate fast-forward to now + 2h.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment thread service/history/historybuilder/history_builder.go Outdated
Comment thread service/history/api/updateworkflowoptions/api.go Outdated
return tsc, stateProp
}

// propagateTimeSkippingToChild makes sure the start time of the child workflow execution

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No changes needed, but just a comment for my understanding. Is my assumption about the behavior is correct: you fast forward 5 minutes, and all child workflows created during that time will skip the time unbounded.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, but we recommend using fast forward with disable-propagation-for-child if child workflows also need to stop in the middle of somewhere and send signals

@feiyang3cat feiyang3cat force-pushed the ts-fast-forward branch 6 times, most recently from 33747da to 55b6e00 Compare June 11, 2026 07:07
@feiyang3cat feiyang3cat changed the title TS: fast forward and propagation policy change (WIP) TS: fast forward and propagation policy change Jun 11, 2026
@feiyang3cat feiyang3cat force-pushed the ts-fast-forward branch 4 times, most recently from f349bb3 to fe2c66e Compare June 11, 2026 22:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants